Transport Level Security: a proof using the 
Gong-Needham-Yahalom Logic 

Walter D Eaves 
February 1, 2008 

Abstract 

This paper provides a proof of the proposed Internet standard Trans- 
port Level Security protocol using the Gong-Needham-Yahalom logic. It 
is intended as a teaching aid and hopes to show to students: the potency 
of a formal method for protocol design; some of the subtleties of authen- 
ticating parties on a network where all messages can be intercepted; the 
design of what should be a widely accepted standard. 

1 Transport Level Security Protocol 

This section provides an insight into the workings of the next generation of au- 



thentication protocol: the Transport Level Security Protocol version 1.0|DA97|, 



the successor to the Secure Sockets Layer|FKK95 . To do this, the Gong- 
Needham-Yahalom, GNY, logic [ pNY9C ] is introduced which is a formal method 



for proving the safety of a cryptographically-based protocol. It is described at 
length in appendix ^ When working through protocols the relevant rule of 
inference will be stated and will refer to those in the appendix. 



The Transport Level Security handshake protocol[D A91], TLS, has an un- 
known heritage, but it has a great deal of similarity to that described in |DS81| 
It is predicated on the existence of readily availabl e public keys: TLS's pre- 
decessor made use of X.509 certificates, see jCCIS^, iss ued by a Certification 



Authority, CA, an example of which is Thawte\THA9£\. A discussion of the 



limitations of certificate technology can be found in Roscheisen's on-line paper 



[|Ros95 | 



TLS has three sub-protocols: 

• Server anonymous 

• Server named, client anonymous 

• Server named, client named 



These differ by who is required to send their X.509 certificates, the key 
exchange protocol is different only when the client is named and thus has a 
public-key that can be used. The messages are shown in figure |l| sent during a 
run of the protocol are more or less the same for all sub-protocols. As can be 
seen, no key issuing server is needed. 
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The TLS is a more complicated protocol than the Kerberos which is de- 



scribed in the appendix §A.3 , before looking at TLS's protocol proof, it might 
be best to examine Kerberos 's. Also, there are some more examples of other 



authentication protocols being investigated and fomid lacking [Low96|. 
A protocol proof has three stages: 

• Message Analysis 

• Pre-conditions Analysis 

• Belief deductions for each message 

Message analysis involves formalizing the content of messages so that they 
contain just keys and identifiers. Pre-conditions analysis formalizes what the 
parties to the protocol assume about the state of keys before undertaking the 
protocol run. Belief deductions analyzes how each party can deduce new beliefs 
when it receives a new message. 

2 Messages for the Named Server Protocol 

There are six message exchanges. There is a provision for more, to settle which 
cryptographic implementations to use and for the client to provide a certificate, 
but this is the basic protocol for a named server to an anonymous client. 




Figure 1: TLS protocol: Messages 
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where 

Kab = F{{Na, Ta, Nb, Tb), N' a) 

and, the behaviour of the pubhc and private keys is: 

{{X}^k]+k = X 
{{X}+k}-k = X 

and 

AB<^ = "server finished" , ABq = "client finished" 
The messages can be summarized as follows: 



Ml A sends a timestamp and a nonce to B. 



M2 B sends another timestamp and another nonce to A. 



M3I B sends its certificate signed by the certification authority; it contains +Kb, 
5's public-key. 



M4 A returns the "pre-master secret" N'a encrypted under +Kb- 



M5 B sends a hash of the session key, a tag indicating the protocol stage ^i?50 
and all preceding messages exchanged to A. 



Mq a sends a hash of the session key, a tag indicating the protocol stage ABq 
key and all preceding messages to B. 



3 Pre— Conditions 

Certificates 

1. Some Expectations 

A expects to use C as the certification authority and expects to use B, so 



A3 {C) A3 (B) 



(li) 



^Actually all stages of the protocol are marked with a stage identifier, but it is not necessary 
to consider all of them. 
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2. Using Them 

The role of the unseen certification authority, C, is pivotal. Even though 
C has used the private key —Kc to create the certificate, this key is not 
used again. 



B\=A\= C, A 1= C (lii) 

The two parties rely on the public-key being available. A must be able to 
get Kc: 



A 9 +Kc, B\=A3 +Kc (liii) 

3. Trusting in them 

The pre-conditions regarding B's certificate are as follows. A and B both 
trust C to deliver the correct identity with the public key. 



A\=C\^{+Kp,{P)), B\=C\^{+Kp,{P)) (liv) 

4. Meaning of the contents 

For A the assumption underlying a certificate is that the public-key is the 
public-key of the named party. 

A \= i+Kp, (P)) -^C\= P (Iv) 

And A believes C when C names a key: 



A\=C\^^-^''P (Ivi) 



System Capabilities 



1. B believes that A can generate a nonce and keep it secret to pass it on as 
the pre-master secret. 



B\=A\^#{X), B\=A^A (Ivii) 

2. A and B have both assumed that the other can generate the master secret 
if presented with the components. 



A\=B\^ F{X, Y), B\=A\^ F{X, Y) (Iviii) 
and, of course, they do 

B\^F{X,Y), A\^F{X,Y) (lix) 
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3. B has a private-key and holds his own certificate. 



B3-Kb, B3{+Kb,{B),{C)}-Kc (Ix) 

Note that the format of a certificate does includes a statement of the 
identity of C. Although not used in this protocol it is an important part 
of it since it allows the public-key of C to be checked. 



4 Belief Deductions Analysis 



1. Messages [Mi| received by B and IM2I received by A 

These nonce and timestamp exchanges are important, because they are 
used in the generation of the key. The vindication is the appearance of 
the time-stamp, which is definitely fresh, and the the rule (Fl) freshens 
the nonces. 



A3 Ml, M2 By (|P1|) B 3 Ml , M2 By 

A 3 Nb,Tb, Na, Ta and B 3 Na, Ta, Nb, Tb 
A\=#{Nb) B\=#{Na) 



(2i) 



2. Message M3 received by A 

A receives the certificate from, presumably, B. By (lii), (liii) and (U), A 
now has: 



A\^C\^{+Kb,{B),{C)}^Kc 
and can decrypt the contents to discover: 



By dli^) and Q 



Ch i+KB,{B)) 



By dl^) and © 



A |=+^^B 



And of course 



A 3 A'h By (|PlD. 

A 3 M4 Because A creates it. 



(2ii) 



Notice that A does not know that the sender of this message was B. 
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3. Message M4 received by B 



B gains knowledge of the following: 

B 9 M3 Since it sent it 



E 9 M4 By (PI) 



(2iii) 



From which by 



where {S) is N' a- 

B <\ N'a 
B 9 N'a 



This is something of an innovation: N' a has not been established as a 
shared secret by the conventional method of passing it along a channel 
secured by a long-term key or comparing it to a pre-stored hash, but it 
will be established as a secret by the subsequent correct operation of the 
protocol. 

Since N' a came under cover of the public key and it will be later identified 
as unique to the sender, it is a shared secret, so by (Ivii). 



b\^aT4-b 

B \^#{N'a) 



Now by and @} 



B 3 Kab 
B |=# {Kab) 
■:B3 Na.Nb,Ta,Tb 

B can now construct the response message: 

B 3 Ml, M2, M3, Mi 

B 3 H{Kab,AB5, (Afi, M2, M3, M4)) 



4. Message M5 received by A 

A now receives a message from B which can only be understood correctly, 
if both A and B have agreed upon Kab ■ 

A performs some pre-calculations: 

A 3 Kab 
■.■A3N'a,Na,Nb,Ta,Tb 
A 3 H{Kab, AB5, {Mi,M2, M3, M4)) 



Because A has been collecting the messages as well (lix) and holding all 
previous messages (|2|) and (pii|). 

By ( PI ) A can decrypt the message 

A <iH{KAB,AB5, (Ml, M2, M3, M4)) 

A \=H{Kab,AB5, {Mi,M2, M3, M4)) 

■^B3 H{Kab,AB5,{Mi,M2,M3,M4)) 
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A can now make a series of justified conclusions, by (|^) 

A\=B3 N'b,Kab 
A\=B3 Mi,M2,M3,M4 
A\=B3Na,Ta,Nb,Tb 

A can now validate the identity of the other party: 

A\=B\^{Nb,Tb) A\=B<A'h 

A\=B\=A\^{Na,Ta) A\=B\^M2 

a|=s|=a'H-b A\=B\^M3 

A\=B |=# {Kab) A\=B < M4 



(2iv) 



It should be clear now why the key Kab is hashed into the hash signature 
H{Kab, AB5, (Ml, M2, M3, M4)). A hash is only validated by inclusion 
of a secret and a nonce, see (P3|), the key Kab is both. 



5. Message Mq received by B 



By a similar argument to that used for A, it is clear: 

B\=A\^ N'a B\=A\^ Ml 

B\=A\=B\^{Nb,Tb) B\=A<M2 

B\=A\=a''A''B B 1= a < M3 

B\=A\=i^{KAB) S|=AhM4 



(2v) 



Since A could only generate this message if in possession of Kab , B can 
deduce that A is the party with whom it shares the key and the whole 
protocol run is current. 

5 Summary: Innovations and Possible Attacks 

Summary The Transport Level Security handshake protocol is quite inge- 
nious: it lets A send a random message under a public key which is used as an 
identifying secret shared by the parties before it has been established as such. 
A challenge and response protocol, the challenge is issued in plain-text and the 
response returns it as cipher-text, so that the challenger can verify that the 
responder knows the shared session key. This protocol is effectively a challenge 
and response protocol with the generated session key, which is created from the 
secret sent under the public-key. 

The protocol is also exemplary in its use of stage identifiers and hash digests. 



The stage identifiers change the hash digest between messages M5 and Mg . The 
hash digests validate the whole protocol run. 
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Attacks The critical point of the protocol is the transmission of the public- 
key with which the client should respond with a nonce encrypted under it. 
The man-in-the-middle attack is well known here: all that need be done is to 



intercept M3 and substitute a bogus certificate. The fraud then hinges upons 



the expectations of A, (|li|). 

1. Impersonate C and B 

If A is not expecting to use C or B then the attacker, M, can substitute 
a different certificate for another service: D. 

2. Impersonate B 

If A is not expecting to use B but is expecting a certificate issued by C 
then M can create a service D and attempt to have C issue a certificate 
for it. 

It is quite easy to provide a service that looks like B and appears to be at the 
address of B this is rather more difficult with a certification authority because 



the public certification scheme proposed in |[TU89| is based upon the following 



• Certification authorities are well-known in that their addresses and public- 
keys can be obtained from many sources. 

• Certificates contain lists of certification authorities which allow a client to 
match known certification authorities to those found in the certificates. 

Certification authorities currently do nothing other than provide certificates, 
so all a client obtains from a certificate is some accountability. If defrauded the 
client can attempt to locate the server who perpetrated the fraud. 

Another Useful Feature One of the provisions of TLS is to allow the server 
to pass to the client another key to use in place of the certificate key. This may 
be necessary for any of the following reasons: 

• The client lacks an implementation to encrypt with the server's public-key. 

• The server does not wish to use its public-key. 

• Restrictions on key size require that a smaller or larger key must be used. 

The client would receive a different public-key but that must be signed under 
the certificate key for the client to have any faith in it. If the client had chosen 
to use the alternative key because it lacked an implementation, it would still 
need to decrypt under the certification authority's key, it is unlikely that the 
client would be able to do this and not make use of the server's certificate key. 

The alternative cryptosystem to system used for certificates is the Diffie- 



Hellman public-key system|DII77 



6 Other sub-protocols 

The protocol described above was the named server protocol, where the server 
must provide a certificate. There are two other sub-protocols. 
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6.1 Anonymous Server 



In this variant, the server is anonymous and creates a pubhc and private key 
pair to be used to estabhsh the session key. It would usuaUy use the Diffie- 
Hellman scheme in this case and would simply send to the client the public key 
instead of the certificate. This does not weaken the protocol at all, the client 
and the server will be able to mutually authenticate one another, but the server 
is unknown to the client and to a certification authority. There is no chain of 
accountability that could help to locate a fraudulent server. 

6.2 Named Client and Server 

This variant provides some accountability to the server of the client's identity 
and it relies upon the client having a certificate. The protocol is the same as the 
named server protocol, but the server can request a certificate from the client 
prior to the client sending the pre-master secret. If the client has no certificate 
it replies by returning no certificates, whereupon the server can take its own 
action, which may well be to raise an error and not complete the protocol. 



7 Summary 

TLS, hke its predecessor the Secure Socket Layer, SSL, does provide both parties 
with a mutual belief that the shared session key is a fresh secret. It also, like 
SSL, can provide the client with some account of the server's Internet location 
and, unlike its predecessor, it does support mutual authentication certificate 
exchange. Suffice to say that identities can be securely established — using X.509 
certificates — and that a session key can be securely established. 

A protocol proof is just a basis for a secure implementation. The software 
engineering of the authentication protocol has to be considered. An example 
of such a failure to ensure that a software implementation was invulnerable 
to attack can be found at [|CER98 |. The problem with that implementation 



was that error messages proved to be too informative allowing a sophisticated 
intruder to recover a session key more quickly than by key trial. Lowe's paper 



Low96| has some other implementation attacks. 
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A Appendix: Gong— Needham— Yong Logic 



This is only a cursory introduction to this simple proof system, despite stimu- 
lating a great deal of research interest it is relatively unchanged. 



A.l Brief History 

Authentication protocols had been developed and discussed, in particular the 
CCI TT X.50 9 protocol of 1987 I jCCISSt was the source for some debate and it 
was [BAN90|, which proved a weakness existed in it. The protocol was extended 
by GNY9C1| and it has been adapted and used in other contexts, [ABLP91|. It 
may even have been superceded by a calculus that is somewhat less intuitive 
[ |AG98| . It is now used principally to illustrate that there is more to secure 
information that just have believing it to be so, for which see [XZX97| and 
[|Low96[. 



A. 2 The Logic 

Notation A.l (Formulae). Formulae is the name used to refer to a bit- 
string. Certain useful operations can be applied to bit strings, which are given 
below. X and Y range over formulae; S over formulae that are secrets and K 
over formulae that are keys. 

(AT, Y) Resulting bit-string is a concatenation of two formalue. 

{X}k and {A}-^ Resuhs are bit-strings are X encrypted and decrypted un- 
der a symmetric cryptosystem with key fC, respectively. 

{X}^K and {X}-K Bit-string results are X encrypted under the public key 
and under the private key, respectively, of an asymmetric cryptosystem 
with public key +K and and private key —K. 

H{X) Result is X after having been subjected to a one-way function. 

-F(Ai, A2, • • ■ ; A„) Bit-string is the result after applying the many-to-one func- 
tion _F, which is an invertible and computationally feasible in both direc- 
tions, to all of Ai, A2, ■ • • , A„. 



Notation A. 2 (Statements). Statements make an assertion about a property 
of a formula. P and Q denote principals — clients, agents and servers: A is a 
message; K a key; S a secret. 

P <\ X P is told the message A. 

P 3 X P holds or can obtain the message A. 

P X P has once conveyed A. 

P \= X P believes the message A. 

P \=ij^ (A) P believes that A is a fresh statement, not seen before in this run 
of the protocol. X is often known as a nonce. (Note freshness is a belief 
relative to a principal). 
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p 

p 
p 
p 



=4> (X) P believes that X is recognizable: P is able to decode X it has a 
recognizable transfer syntax. (Same note as above). 

= P ^ Q P believes it shares the secret S with Q. 

= ^ Q P believes that +K is the public key of Q. 
= Q |=> C P believes that Q has jurisdiction over C. 

= Q \^ Q \= * P believes that Q has jurisdiction over all of beliefs held by 
P. 



X C X is a message expressing the statement C. 

Ci, C2 Conjunction of two statements: Ci and C2. 

*X The message did not originate from its current location. 

Remark A.l (Epochs). Time is divided into two epoch: past and present. 
The present is the run of a protocol. The past is all other runs of protocols. 
P 1= X, if a pre-condition, is valid for all of the present. Beliefs held in the 
past are not necessarily carried forward to the present. 

Remark A. 2 (Encryption). There are some assumptions about encrypted 
messages: 

1. Messages are assumed to be encrypted as a whole. 

2. For recipients: each encrypted message contains enough redundancy to 
allow the recipient to determine, on decryption, that the right key has 
been used to do so. 

3. For senders: each message contains enough information to allow senders 
to detect and ignore messages that originated from them. 

Also, 

1. The key cannot be deduced from the encrypted message. 

2. The message; can be understood by only those who possess the correct 
decrypting key. 

The logic of authentication is a set of inference rules. The premisses are 
stated above the deductive line, the conclusion below. 

Rule A.l (Universal— Local) . This is an axiom from modal logic. 

Ci P\=Ci , 
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Rule A. 2 (Being— Told). The rules about the "being-told" operator <l. 

P <*X 



P <\X 



(Tl) 



( ri ) says that if one is in receipt of a message that did originate from elsewhere, 



one is still aware of it. 



P <l(X,Y) 

^ ' ' (T2) 



(r2) says that if one is in receipt of a composite message one is in receipt of 



each part of it. 

P<i{X}K,P3K 



(T3) 



P <]X 

( [r3|) is simple one must possess the right key to understand encrypted messages. 

P<^{X}+K,P3-K 

P <iX ^ ' 

( [r4D is the same statement for public-key systems, decrypting with the private 
key. 



P < F{X,Y),P3 X 
P <Y 



(T5) 



( r5 ) is the same statement for a combination function. 

{{X]^k]+k = X,P<i {X}^K, P3+K 
P <iX 



(T6) 



(r6) is the same statement for public-key systems, but decrypting with the pub- 
lic key. Note with this rule, the requirement that encryption with a public-key 
and then with the private-key yields the original message. Not all asymmetric 
cryptosystems have this property. 

Rule A. 3 (Possession). Rules for the 9 operator: 

P <iX 



P3 X 



(PI) 



(PI) states that one can possess what one is told. 

P3 X,P3Y 



P 3 (X,y),P 9 F{X,Y) 



(P2) 
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( p2[ ) states that if in possession of two messages one can create a concatenation 
and apply a function to them. 



P3 X 

( p3[ ) possession of a composite yields possession of the components. 

P3 X 



P 3 H{X) 



(P3) 



(P4) 



( |P4|) possession of a message allows the hash of it to be generated. 

P 9 F{X, Y),P3X 
P3Y 



(P5) for the combination function F{), given X, Y can be determined. 

P3 K,P3 X 
P3{X}k,P3{X}],' 



(P5) 



(P6) 



(P6) one can encrypte and decrypt with key and message. 

P3+K,P3X 
P 9 {X}+K 



(P7) 



(P7) encryption imder public-key. 

P 3 -K, P3 X 
P 3 {X)^K 

( |P8| ) encryption under private-key. 



(P8) 



Rule A. 4 (Freshness). These rules specify what can be deduced from fresh 
messages. 



P\^*{X) 



P\=#iX,Y),P\=#iF{X)) 

P\=#{X),P3K 
P\^#{{X}k),P\^#{{X}-^') 

P\=^ {X),P3+K 
PN#({X}+k) 

P|=# {X),P3-K 
PN#({X}_^) 



(Fl) 



(F2) 



(F3) 



(F4) 
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P\^#i-K) 

P\^*{-K) 
P\=#{+K) 

P\=^{X),P\=#{K),P3K 
P\^#{{X}k),P\^# ({X}^^) 

P\=^{X),P\=#{+K),P3+K 
P\^#{{X}+k) 

P\=^{X),P\=#{-K),P5-K 
PN#({X}_k) 

P\=#{X),P3X 
P\^#iH{X)) 

P|=# {H{X)),PbH{X) 



(F5) 



(F6) 



(F7) 



(F8) 



(F9) 



(FIO) 



(Fll) 



Rule A. 5 (Recognizability). When one can claim a formula is recognizable. 

P .^'AX) 



P\=<j>{X,Y),P\=F{X) 

P\=<j>iX),P3 K 
P\^cP{{X}k),P\^^{{X}~^') 

P\=4>{X),P3+K 
P\=cI>{{X}+k) 

P\=<f>iX),P3 -K 
P\^<I,{{X}.k) 

p\=4,{x),P3X 

P\^ct>{H{X)) 

P 3 H{K) 
P\^<P{X) 



(Rl) 



(R2) 



(R3) 



(R4) 



(R5) 



(R6) 
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Rule A. 6 (Message Interpretation). A secret 5* used for identification is 
denoted {S) — tliis is to allow it to be distinguished from other secrets that 
might be in the message. 

P < *{X}k, P3K,P\=P^Q,P\=c^ {X),P |=# (A, K) 

P\=Q\^X,P\=Q\^{X}k,P\=Q^K ^ > 

This specifies the flow of beliefs on receipt of an encrypted message under a 
shared-key cryptosystem. Notice that P |=# {X,K), either the key is fresh or 
the message is fresh. Usually the message is freshened by adding a nonce (or 
timestamp). 



P< *{X,{S)}+K, 

P3 {-K,S), 

P\= +^>, 

P\= P^Q, 
P\= <^(A,5), 

#iX,S,+K) 



P\= Qh(A,(5)), 
P\= Q\^{X,{S)}+K, 
P\= Q3+K 

Message sent encrypted imder a public-key. Normally such messages are anony- 
mous, since anyone can use the public-key, but an identifying secret S is passed. 

P < *H{X, jS)), P 3 (A, S),P \^P^Q,P |=# (A, S) 

P\^Q\^{X,{S)),P\^Q\^H{X,{S)) ^''> 

Passing a hashed message. 



P < {X}_K,P3 +K,P 1= t^Q,P |=0(A) 

P|=Q|~A,P|=Q|~{A}_x ^ ' 

Passing a message encrypted under a private-key does not require an identifying 
secret. 



P < {X}_K, Pb+K,P\=^-^Q,P 1=^ (A), P |=# (A, +K) 

P\^Q3{-K,X) ^ > 

P|=QhA,P|=# (A) 
P\=QbX 

P\=Q\^{X,Y) 



(16) 
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Rule A. 7 (Jurisdiction). Rules governing the meaning of jurisdiction. 

P\=Q\^C,P\=Q\=C 
P\=C 



(Jl) 



P\=Q\^Q\=*,P\=Q h {X ^ C),P N# {X) 
P\=Q\=C 



(J2) 



P \= Q \^ Q \= *,P \= Q \= Q \= C 
P\=Q\=C 



(J3) 



Definition A.l (Goals of Authentication). For an authentication there are 
a number of possible goals: 

1. Assurance: to assure another principal that a message has been received. 
P\=Q<X. 

2. Exchanging secrets: to send to another principal a secret: 

P\=P^Q. Q\=P^Q 

3. Exchanging secrets: to send to another principal a secret and be assured 
of it: 



P\=Q\=P 



Q\=P\=P^Q 



A. 3 Example: The Kerberos Protocol 



As an illustration of the use of the BAN logic, the Kerberos | NT94 protocol 
will be analyzed. This protocol is supported within the emerging Transport 
Level Security specification. It is designed to establish a session key between 
two principals given a trusted key server. 




Figure 2: Kerberos Protocol: Messages 



Referring to figure the protocol uses three messages to authenticate the 
sender and the fourth for mutual authentication of the receiver to the sender. 
The messages appear in order below: 
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-* S 


S- 




A- 


^ B 


B - 


-^A 



{A,B) (Ml) 

{Ts, L, Kab,B, {Ts, L, Kab,A}kss}k^s {M^) 

{Ts,L,Kab,A}kus,{A.Ta}k^u (Ma) 

{Ta + 1}k.s (M4) 



Ml A indicates that it wants a session key with B by sending two identifiers to 
S. 



M2 S returns a message that is encrypted under for A only, it contains a times- 
tamp, a session key, a restatement of the target for which it can be used 
and, the ingenious part, an encrypted message for B. 



M3 A sends the encrypted part on to B, which contains the timestamp, the 
session key and the other party to the session key. As well as that, A 
sends a challenge, encrypted under the session key. 



M4 B responds to the challenge by sending back the timestamp with a pre- 
determined calculation applied to it. 

The timestamps Tg and Ta have a lifetime L. Effectively, these act as nonces, 
so they shall be named as such: Ns and Na- There are some preconditions about 
key distributions: 

Al^A'i^'S, B\=b'^A'S (3i) 
S\=a''A'S, S\=b''A'S (3ii) 



Sl-A^A^'B (3iii) 



They all hold long-term keys with each S and vice-versa. 

AbKas, Bb Kbs (4i) 

SbKas, S3 Kbs (4ii) 
There also some preconditions on jurisdiction and nonces: 

A\= {S \^ A^A" B), B \={S \^ A^A"" B) (5i) 

A\=#{Ns), B\=#iNs), B\=#{Na) (5ii) 
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Finally, the protocol can be analyzed: (Mi) establishes no new beliefs, but 
with (|Mj), the following are established: 



X ^Ns, {A B) 

Y ^Ns, {A B)}i,,, 
^A\=S\^{X,Y) 

By initial key distribution, (TS) and (|^) 

From X ^A< {Ns, {A ^"^4^ B)) 



By (|T3D 



By dFlD 



^A\=A'"A''B,A3Kab 



By pre-conditions and (1J 



B on receipt of ( M3 ) can establish the following: 
M3 ^ {X,Y) 

where 



X ^ {Ns, (A B)}k, 



Y ^ {Na}k., 



From X 



^B \=S\r^X 
By initial key distribution and (|^) 



^B < {Ns, {A B) 



By (T3) 



^B |=# (a "^A- 
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By W3 



^B\=A'"A''B,A3Kab 



By (Tl) and jurisdiction pre-conditions 
From Y \= A |- Na 

By dll 



=>B \=A\=A ^A'' B,B\=A3 Kab 



By® 



A on receipt of (M4) can establish the following: 

M4 ^ {Na}k.s 

where 

^A <\ Na 

By dH 

^A \=B\=A B,A\=B3 Kab 



By (Fl) and (O) 
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